home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 384 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.4 KB

  1. From: "Eugene Lazutkin" <INT@msn.com>
  2. Message-ID: <UPMAIL04.199602192354280583@msn.com>
  3. X-Original-Date: Mon, 19 Feb 96 23:49:01 UT
  4. Path: in2.uu.net!bounce-back
  5. Date: 20 Feb 96 07:15:52 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Organization: -
  8. Newsgroups: comp.std.c++
  9. Subject: RE:  Portability. Modules. WAS: RE: Are all Windows programs 
  10.     ill-formed?
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMSl1geEDnX0m9pzZAQFVcAF5AR1Q85NvC1wBpg9XO5ni6I5JAkvj1I6J
  13.     vIOAOG1Z6DUPBAJLGRBAUKXFKIj/oG0f
  14.     =XM7Z
  15.  
  16. On     Tuesday, February 13, 1996 7:48 AM,     
  17.     James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> wrote:
  18. > In article <01BAF61B.3131B100@dino.int.com> Eugene Lazutkin
  19. > <eugene@int.com> writes:
  20. > |> On     Tuesday, February 06, 1996 9:18 PM, 
  21. > |> rich@kastle.com (Richard Krehbiel) wrote:
  22. >     [...]
  23. > |> Another point of non-portability is #pragmas.  Static containers are
  24. > |> almost useless unless you can specify the order of their
  25. > |> construction/destruction.
  26. > This depends on the design of the container.  See below for two ways
  27. > of handling this.
  28. > |> Borland provides you with #pragma
  29. > |> startup/exit (am I correct with names?). With this tool you can specify
  30. > |> a priority. It is not a ultimate medicine but it helps a lot!
  31. > It helps make your programs non-portable, you mean:-) (as you point
  32. > out).  There are better solutions.
  33.  
  34. I don't like this solution either.  But it works.  See below.
  35.  
  36. > The oldest one, rarely used except for the simplest cases today, is to
  37. > design the list such that the initial initialization to 0 is adequate,
  38. > and give it a special no-op constructor.  Thus, for example, my
  39. > command line parser class maintains a list of options (staticly
  40. > declared objects); a NULL pointer signifies an empty list, and the
  41. > constructor does nothing.  Thus, it doesn't matter if the options are
  42. > constructed (and register themselves) before the list.
  43.  
  44. It doesn't help to create a simple double-linked ring.  Not all 
  45. containers can be built on a single-linked list or a tree structure.
  46. E.g., any member of a double linked ring can exclude itself from the 
  47. list automatically by its destructor at any time.  You can't do it
  48. with single-linked list or with double-linked list (not ring).
  49.  
  50. BTW, who frees the allocated memory?  When?  How can I specify the 
  51. order of destruction?  ObjectSpace's STL has problems with that.
  52. The program using this STL will leak.  They can't eleminate this 
  53. problem.  OK, they have a work around.  But it is very inefficient:
  54. they use per-object allocators instead of per-class.
  55.  
  56. > The more frequent solution today is to have a function returning a
  57. > reference to a local static object.  The object will be constructed
  58. > the first time the function is called.  The enrolment functions in the
  59. > Item's call the function to get the actual list object.
  60.  
  61. Does this static object have any constructors?  Or its components?
  62. Is it based on some class without constructors?  If not, who will
  63. be initialize it?  And how?  Who will deinitialize it?  A lot of
  64. problems.
  65.  
  66. Of course, both these solutions work just fine in certain specific 
  67. cases.  But it is not a generic answer.  It is a trick.
  68.  
  69. > I often encapsulate the above solution in a SharedList interface
  70. > class.  All instances of the SharedList actually refer to the same
  71. > list object.  The SharedList only contains a pointer to the actual
  72. > list object, and forwards all requests to it.  The pointer is
  73. > initialized by calling the function above in the constructor.
  74. > |> Alternative way: include all items into the container manually and
  75. > |> don't forget to do this initialization every time when you use this
  76. > |> container in your program.
  77. > This is extremely error prone (as you also point out).  If you are
  78. > willing to accept that all of the objects are known in the same
  79. > compilation unit, you might as well define them there, and let the
  80. > guaranteed order of construction within the compilation unit do the
  81. > trick.
  82.  
  83. This is C++, not Pascal.  We have separate units.  I think it is too
  84. strong requirement to put some logically different items together.
  85. I think it is too error-prone.
  86.  
  87. Eugene Lazutkin
  88. eugene@int.com
  89. ---
  90. [ To submit articles: try just posting with your news-reader.
  91.                       If that fails, use mailto:std-c++@ncar.ucar.edu
  92.   FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  93.   Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  94.   Comments? mailto:std-c++-request@ncar.ucar.edu.
  95. ]
  96.